Subject: Resending note

From: "Mel Jones (Tie: 444-4363)" <[email-masked]>
Date: Fri, 22 Oct 93 15:21:38 EDT

All:  I'm resending the note below -- some people got the
response from Jeff Hildebrand, but not the original note....

Regards,
Mel
 - - - - - - - - - - - - resent note text - - - - - - - - - - -
Date: 15 October 1993, 16:17:13 EDT
From: Mel Jones               Phone: 919-254-4363    JONES    at RALVM6
To:   ciw-general at ibmstandards.cary.ibm.com,
      ciw-sig-dir at ibmstandards.cary.ibm.com
Subject:  Identifying the directory syntax and encoding

All:

In the meeting minutes from the September CIW I promised to send out a
writeup on how to deal with different underlying directories, DNs, etc.
A proposal is attached below.

This draft includes some of the functionality proposed in the Boeing
proposal from July, plus adds in another concern we'd gotten about
handling future encoding changes.  Suggestions, clarifications,
criticisms, and comments, are welcome.  If possible, I'd like to get some
early/quick discussion on this and then move to include it in the
existing AP proposal if we are all agreed with the functionality (or at
least well-enough agreed to want to see if fleshed out with more detail).

Thanks,
Mel Jones

******************************* begin proposal *************************

Directory Syntax and Encoding Proposal
- - - - - - - - - - - - - - - - - - -

INTRO
At the September CIW, the requirement for a new parameter to clarify the type
of the DN was raised.   Unfortunately, this subject did not receive complete
discussion.  This note outlines the requirements, discusses possible sol-
utions, and makes a proposal for how the existing directory proposal should
be modified.

PROBLEM STATEMENT
In CPIC today, there is no discussion of the details of how the sym-dest-name
is resolved.  A string is passed in; CPIC uses the string to retrieve the
appropriate destination information.  The details of where that information
is stored, what format, what naming syntax for the sym-dest-name, etc., are
all left as "magic" of the implementation.  This same method was used in the
specification of the DN in the existing proposal.  In a perfect operating
environment the naming structure (and implementing directory architectures)
would hide all knowledge of the directory type from the application program.
Unfortunately, this level of agreement on universal naming architectures is
not currently available and programs will be forced to know details of the
underlying directory.

Two specific pieces of information the program may be required to know are
listed below.  Two possible solutions for each (how the program would get the
information) are also listed:

1.  Future implementations of CPIC may need to support multiple directories,
with DNs drawn from different namespaces (or using different naming con-
ventions).  The specific syntax of the DN (or PFID) must be established.

Solution 1A:  Continue to use magic.  The implementation would detail a
method whereby the program installs (specifies) which syntax will be
used.  The string passed to CPIC would be recognized according to the
implementation-specific definition.

Solution 1B:  Pass in a parameter with the DN identifying the syntax
(naming convention) that the DN or PFID uses.  The implementation could
then parse the value appropriately.

2.  Encodings of the DN may be required beyond today's "local" encoding,
because the DN string will be passed to an external process.  For
example, today's proposal follows today's CPIC and assumes an 8-bit
encoding.  Future directory implementations might wish to accept a 16-bit
encoding of the DN (which would need to come through the CPI-C inter-
face).  The encoding method must be specified.

Solution 2A:  Set a CPI-C wide parameter that would define the encoding
method for all parameters (not just the DN and PFID).

Solution 2B:  Set a value specifically to identify the encoding for the
DN.

DISCUSSION OF SOLUTIONS
MULTIPLE DIRECTORIES:  Solution 1A (using magic to determine the correct
syntax) moves the problem back into system configuration and limits porta-
bility of applications.  The principal argument for taking this approach is
that definition of the different DN syntaxes (and how they interact) is a
moving target and if we put something into the interface we may put the wrong
thing in.  The counter-argument (in favor of Solution 1B) is that if we add
the parameter with sufficient room, we can leave open a path for growth.  By
taking Solution 1B now and adding the parameter, we can avoid migration prob-
lems in the future.  The DN types discussed so far could be addressed with
three categories:  1) Default (implementation defined), 2) DCE, and 3) X.500.
Yet another might be NDS to support the syntax of Novell's directory inter-
face.  Other categories could be defined as implementations wished to accept
new/different directory syntaxes.

PARAMETER ENCODING:  Solution 2A seems a good approach at first, but investi-
gation of other parameters in CPIC indicate that most of them are all locally
resolved.  The decision point seems to be whether the program will specify a
parameter that CPIC will resolve (no encoding parameter required) or export
as-is to an external process (which may have different requirements for
encoding).  Using this criteria, the DN becomes the only parameter that
requires an encoding definition.  This is Solution 2B.  At present, two pos-
sible values would be required:  1) Default encoding (which would be inter-
preted as equivalent to existing CPIC usage, or 8-bit), and 2) Unicode (which
would be 16-bit).  Other encodings could be added as needed.

PROPOSED SOLUTION
The proposed solution is to combine Solution 1B and 2B.  Because there are
only three possibilities for the DN type and two for the encoding (and expo-
nential growth in either category isn't expected), it would be possible to
minimize the number of parameters by combining the two into a single param-
eter.  It would be safer, however, to leave the two values separate and use
easily understood names for the two different values:  directory_syntax and
directory_encoding.  These two parameter are easily added to the
Set_Partner_ID call and would apply when either a DN or PFID were provided.
Possible values for the new parameters follow:

directory_syntax (32-bit integer, input):

o   CM_DEFAULT_SYNTAX -- the DN or PFID specified conforms to the default
directory syntax.

o   CM_DCE_SYNTAX -- the DN or PFID conforms to DCE directory syntax guide-
lines.

o   CM_X.500_SYNTAX -- the DN or PFID conforms to X.500 directory syntax
guidelines.

o   CM_NDS_SYNTAX -- the DN or PFID conforms to Novell's NDS directory syntax
guidelines.

directory_encoding (32-bit integer, input)

o   CM_DEFAULT_ENCODING -- the DN or PFID specified is encoded in 8-bit
format.

o   CM_UNICODE_ENCODING -- the DN or PFID specified is encoded in 16-bit
format.

*********************** end of proposal ************************